Server side TFTP flow control

ABSTRACT

Methods and apparatuses for server side flow control. Receive a request from a first client device to multicast a file as a plurality of packets of data from a server device to multiple client device; transmit the plurality of packets of data from a server to the multiple client devices using a multicast trivial file transfer protocol (TFTP); and apply, by the server, one or more flow control techniques not defined by the multicast TFTP.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a National Phase application of, and claims priorityto, International Application No. PCT/CN2005/000263, filed Mar. 5, 2005,entitled SERVER SIDE TFTP FLOW CONTROL.

TECHNICAL FIELD

Embodiments of the invention relate to file transfer. More particularly,embodiments of the invention relate to server side flow control for theTrivial File Transfer Protocol (TFTP).

BACKGROUND

Trivial File Transfer Protocol (TFTP) is a simple file transfer protocolthat operates in a lock step fashion. That is, each packet isacknowledged by a receiving client and the server does not transmit thesubsequent packet until the acknowledgement is received for the previouspacket. One embodiment of TFTP is described formally in Request forComments (RFC) 1350, Rev. 2, published July 1992. Because of simplicity,TFTP is used in pre-boot environments and/or embedded systems. Typicalusage may include download of an operating system loader or upgrading ofa system image or BIOS.

However, as file sizes increase and/or packets are lost duringtransmission, the performance provided by TFTP may be unacceptablebecause large file sizes and repeated transmission of packets mayoverload network infrastructure components. Thus, TFTP may beinsufficient for more complex file download conditions.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example, and notby way of limitation, in the figures of the accompanying drawings inwhich like reference numerals refer to similar elements.

FIG. 1 is a block diagram of a network that may connect a server tomultiple clients.

FIG. 2 is a flow chart of one embodiment of a main flow of operation ofa server device that may provide server side flow control of a TFTPand/or multicast TFTP session.

FIG. 3 is a flow chart of operation of one embodiment of an uploadrequest handler executed by a server device that may provide server sideflow control of a TFTP and/or multicast TFTP session.

FIG. 4 is a flow chart of operation of one embodiment of a unicastdownload request handler executed by a server device that may provideserver side flow control of a TFTP and/or multicast TFTP session.

FIG. 5 is a flow chart of operation of one embodiment of a multicastdownload request handler executed by a server device that may provideserver side flow control of a TFTP and/or multicast TFTP session.

FIG. 6 is a block diagram of one embodiment of an electronic system.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth.However, embodiments of the invention may be practiced without thesespecific details. In other instances, well-known circuits, structuresand techniques have not been shown in detail in order not to obscure theunderstanding of this description.

FIG. 1 is a block diagram of a network that may connect a server tomultiple clients. Server 100 may be coupled with any number of clients(e.g., 140, 150, 160) via network 120, which operate according to anynetwork communication protocol known in the art.

Currently the Trivial File Transfer Protocol (TFTP) may be used totransfer files between devices. In general, TFTP is a transfer protocolthat is simpler to use than the File Transfer Protocol (FTP), butprovides less functionality. For example, TFTP does not support userauthentication or directory visibility. TFTP uses the User DatagramProtocol (UDP) rather than the Transmission Control Protocol (TCP). Oneembodiment of TFTP is described formally in Request for Comments (RFC)1350, Rev. 2, published July 1992.

TFTP has been expanded to include a multicast option as described in RFC2090, published February 1997. Multicast TFTP classifies client devicesas active clients or passive clients. There is only one active client ata time. The active client communicates with a server to download datausing a stop-and-wait ARQ flow and error control technique to anegotiated group address. Passive clients snoop on the download to theactive client and capture data destined for the group address. When theactive client finishes downloading the data, a passive client isselected as a new active client.

In one embodiment, one client, for example, client 160, may operate asan active client as defined by the multicast TFTP to request download ofa file from server 100. Any number of additional clients, for example,clients 140 and 150, may operate as passive clients as defined by themulticast TFTP to receive packets corresponding to the file requested bythe active client. Upon completion of the download by the active clientone of the passive clients may become a new active client to downloadmissing packets.

In the description herein, the term “packet” refers to any block ofdata, which can be, for example, a predefined, fixed length or variablein length. In one embodiment, a packet is defined by the multicast TFTPdefinition. In alternate embodiments, other packet sizes may be used.

Multicast TFTP does not define techniques for server-side flow control.In one embodiment, a multicast TFTP session may be managed by server 100using one or more flow control techniques described herein. The TFTPstandard relies on a lock-step transfer model in which every packet isacknowledged by the client device before the server transmits asubsequent packet. This does not allow the transfer rate to becontrolled by the server device.

In one embodiment a passive client may join the multicast group duringfile download. For these passive clients, packets transmitted prior tojoining the multicast group may be received when the missing packets areretransmitted to a new active client.

FIG. 2 is a flow chart of one embodiment of a main flow of operation ofa server device that may provide server side flow control of a TFTPand/or multicast TFTP session. The server may monitor a designated portto detect packets that may carry requests for download of a file, 200.In one embodiment, the server device may execute a multi-threadedapplication that includes one thread that monitors the designated port.The designated port may be, for example, UDP port 69 as defined by theTFTP standard; however, other ports may also be used.

When a packet is received via the designated port, the application mayanalyze the packet to determine whether the packet includes a requestfrom a client device, 210. In response to a request from a clientdevice, the application may call the appropriate request handler, 220.After calling the request handler, the application may return tomonitoring the designated port. In one embodiment, at least thefollowing three request handlers are implemented by the applicationand/or by another application executed by the server device: an uploadrequest handler (FIG. 3), a unicast download request handier (FIG. 4),and a multicast download request handler (FIG. 5). In alternateembodiments, additional and/or different request handlers may besupported.

FIG. 3 is a flow chart of operation of one embodiment of an uploadrequest handler executed by a server device that may provide server sideflow control of a TFTP and/or multicast TFTP session. In response tobeing invoked, the upload handler may determine whether thecorresponding request is a duplicated request, 300. If the request is aduplicate request, the upload handler may return because the requestedupload has been processed.

If the request is not a duplicate, 300, the upload request handler maydetermine whether the host server has satisfactory resources availableto process the request, 310. If the server does not have satisfactoryresources available, the upload handler may cause an error packet to besent to the requesting client device, 330. If the server does havesatisfactory resources available, the upload handler may save sessioninformation that may be used, for example, by other request handlers,and the upload request handler may create a thread to service therequest, 320. Server side flow control techniques that may be used inservicing the upload request are described in greater detail below.

FIG. 4 is a flow chart of operation of one embodiment of a unicastdownload request handler executed by a server device that may provideserver side flow control of a TFTP and/or multicast TFTP session. Inresponse to being invoked, the unicast download handler may determinewhether the corresponding request is a duplicated request, 400. If therequest is a duplicate request, the unicast download handler may returnbecause the requested download has been processed.

If the request is not a duplicate, 400, the unicast download requesthandler may determine whether the host server has satisfactory resourcesavailable to process the request, 410. If the server does not havesatisfactory resources available, the unicast download handler may causean error packet to be sent to the requesting client device, 430. If theserver does have satisfactory resources available, the unicast downloadhandler may save session information that may be used, for example, byother request handlers, and the unicast download request handler maycreate a thread to service the request, 420. Server side flow controltechniques that may be used in servicing the unicast download requestare described in greater detail below.

FIG. 5 is a flow chart of operation of one embodiment of a multicastdownload request handler executed by a server device that may provideserver side flow control of a TFTP and/or multicast TFTP session. Inresponse to being invoked, the multicast download handler may determinewhether the corresponding request is a duplicated request, 500. If therequest is a duplicate request, the multicast download handler mayreturn a previously sent acknowledge message to the requesting clientdevice, 505. The acknowledge message may cause the requesting clientdevice to operate as a passive client in the multicast download session.

If the request is not a duplicate, 500, the multicast download requesthandler may determine whether another multicast group is downloading therequested file, 510. If the requested file is being downloaded, themulticast download handler causes the requesting client to become apassive client in the existing multicast download group, 515.

If the requested file is not being downloaded by another multicastgroup, 510, the multicast download hander may determine whether the hostserver has satisfactory resources available to process the request, 520.If the server does not have satisfactory resources available, themulticast download handler may cause an error packet to be sent to therequesting client device, 530. If the server does have satisfactoryresources available, the multicast download handler may save sessioninformation that may be used, for example, by other request handlers,and the multicast download request handler may create a thread toservice the request, 540. Server side flow control techniques that maybe used in servicing the unicast download request are described ingreater detail below.

In one embodiment, to save session information, an application runningon the server may maintain three linked lists (or other suitable datastructures) to save information related to upload sessions, unicastdownload sessions and multicast download sessions. A request handler maythen traverse one or more of the linked lists to determine whether thecurrent request is a duplicate request and/or if the file is beingdownloaded. This may allow the server to combine download sessions whereappropriate.

In one embodiment, one or more request handlers monitor host systemresources to determine whether sufficient resources are available toprocess a request. The resources may include, for example, networkbandwidth, host computing capacity, memory usage, number of activethreads, etc. The resource criterion may be different for differentrequest handlers. As an example, if the block size of a request is L andthe bandwidth of the server connection is B, then a new request may berequired to satisfyΣ(L/B)≦½,which would allow each active session to send at least one packet everyhalf second, Other criterion may also be used.

In one embodiment, the server may monitor packet loss rate and adjustthe packet transmission rate based, at least in part, on the packet lossrate. For example, a transmission delay may be computer according to:

If (packet is lost){  If(send delay is zero){   Set send delay to 1  }else if(send delay > timeout/4){   Set send delay to timeout/4  } Double send delay }else{  decrease send delay by 1 every 10successfully received packets until 0 }Other delay computations may also be used.

In one embodiment, the techniques of FIGS. 2-5 can be implemented asinstructions executed by an electronic system. The instructions may bestored by the electronic device or the instructions can be received bythe electronic device (e.g., via a network connection). FIG. 6 is ablock diagram of one embodiment of an electronic system. The electronicsystem illustrated in FIG. 6 is intended to represent a range ofelectronic systems, for example, computer systems, network accessdevices, etc. Alternative systems, whether electronic or non-electronic,can include more, fewer and/or different components. The electronicsystem of FIG. 6 may represent a server device as well as the one ormore client devices.

Electronic system 600 includes bus 605 or other communication device tocommunicate information, and processor 610 coupled to bus 605 to processinformation. While electronic system 600 is illustrated with a singleprocessor, electronic system 600 can include multiple processors and/orco-processors. Electronic system 600 further includes random accessmemory (RAM) or other dynamic storage device 620 (referred to asmemory), coupled to bus 605 to store information and instructions to beexecuted by processor 610. Memory 620 also can be used to storetemporary variables or other intermediate information during executionof instructions by processor 610.

Electronic system 600 also includes read only memory (ROM) and/or otherstatic storage device 630 coupled to bus 605 to store static informationand instructions for processor 610. In one embodiment, static storagedevice 630 may include an embedded firmware agent that may have aninterface compliant with an Extensible Firmware Interface (EFI) asdefined by the EFI Specifications, version 1.10, published Nov. 26,2003, available from Intel Corporation of Santa Clara, Calif. Inalternate embodiments, other firmware components can also be used.

Data storage device 640 is coupled to bus 605 to store information andinstructions. Data storage device 640 such as a magnetic disk or opticaldisc and corresponding drive can be coupled to electronic system 600.

Electronic system 600 can also be coupled via bus 605 to display device650, such as a cathode ray tube (CRT) or liquid crystal display (LCD),to display information to a user. Alphanumeric input device 660,including alphanumeric and other keys, is typically coupled to bus 605to communicate information and command selections to processor 610.Another type of user input device is cursor control 670, such as amouse, a trackball, or cursor direction keys to communicate directioninformation and command selections to processor 610 and to controlcursor movement on display 650. Electronic system 600 further includesnetwork interface 680 to provide access to a network, such as a localarea network. Network interface 680 may further include one or moreantennae 685 to provide a wireless network interface according to anyprotocol known in the art.

Instructions are provided to memory from a storage device, such asmagnetic disk, a read-only memory (ROM) integrated circuit, CD-ROM, DVD,via a remote connection (e.g., over a network via network interface 680)that is either wired or wireless providing access to one or moreelectronically-accessible media, etc. In alternative embodiments,hard-wired circuitry can be used in place of or in combination withsoftware instructions. Thus, execution of sequences of instructions isnot limited to any specific combination of hardware circuitry andsoftware instructions.

An electronically-accessible medium includes any mechanism that provides(i.e., stores) content (e.g., computer executable instructions) in aform readable by an electronic device (e.g., a computer, a personaldigital assistant, a cellular telephone). For example, amachine-accessible medium includes read only memory (ROM); random accessmemory (RAM); magnetic disk storage media; optical storage media; flashmemory devices; etc.

Reference in the specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the invention. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment.

While the invention has been described in terms of several embodiments,those skilled in the art will recognize that the invention is notlimited to the embodiments described, but can be practiced withmodification and alteration within the spirit and scope of the appendedclaims. The description is thus to be regarded as illustrative insteadof limiting.

1. A method comprising: executing, by a server device, a multi-threadedapplication having at least one thread to monitor a port of the serverdevice for received requests from a plurality of client devices;executing, by the server device, at least three request handlers tomanage any of the received requests from the plurality of clientdevices, the at least three request handlers comprising an uploadrequest handler, a multicast download request handler and a unicastdownload request handler; detecting, by the server device, that amulticast request is received from a first client device of theplurality of client devices; invoking, by the server device, themulticast download request handler in order to save session informationregarding the received multicast request and create another thread ofthe multi-threaded application to service the received multicastrequest; wherein servicing the received multicast request by the anotherthread further comprises: transmitting the plurality of packets of datafrom the server device to the multiple client devices using a multicasttrivial file transfer protocol (TFTP) as a TFTP-compliant flow; andapplying one or more flow control techniques not defined by themulticast TFTP to the TFTP-compliant flow, wherein the flow controltechniques comprise determining whether the server device has sufficientresources to satisfy the request based on a block size corresponding tothe request and an available bandwidth, and sending an error packet tothe first client device if the server device does not have sufficientresources to satisfy the request, wherein applying, by the server, oneor more flow control techniques not defined by multicast TFTP comprisedelaying a start of the transmission of the plurality of packets,wherein delaying includes if a packet is lost and a send delay isdetermined to be zero, the send delay of zero is set to one, and if thesend delay is determined to be greater than timeout/four, the send delayis set equal to the timeout/four, wherein the send delay is doubled orthe send delay is decreased by one for a number of successful packetsreceived until the send delay reaches zero, wherein the number ofsuccessful packets received includes ten.
 2. The method of claim 1wherein applying, by the server, one or more flow control techniques notdefined by multicast TFTP comprises: determining whether a request todownload the file is a subject of an existing multicast downloadsession; and causing the multiple client devices to join an existingmulticast group corresponding to the existing multicast downloadsession.
 3. The method of claim 1 wherein applying, by the server, oneor more flow control techniques not defined by multicast TFTP comprisesmodifying quality of service based, at least in part, on resourceconditions.
 4. The method of claim 3 wherein modifying the quality ofservice comprises one or more of: modifying block size and modifyingtimeout length.
 5. The method of claim 1 wherein applying, by theserver, one or more flow control techniques not defined by multicastTFTP comprises reducing a packet transmission rate.
 6. The method ofclaim 1 wherein applying, by the server, one or more flow controltechniques not defined by multicast TFTP comprises retransmitting a mostrecently transmitted packet in response to receiving an unexpectedpacket.
 7. A server device comprising: a network interface to receivemessages from a plurality of client devices including requests todownload a file stored by the server device; a memory coupled with thenetwork interface to store the file; and a processor coupled with thememory and the network interface, the processor configured to: execute amulti-threaded application having at least one thread to monitor a portof the server device for received requests from the plurality of clientdevices; execute at least three request handlers to manage any of thereceived requests from the plurality of client devices, the at leastthree request handlers comprising an upload request handler, a multicastdownload request handler and a unicast download request handler; detectthat a multicast request is received from a first client device of theplurality of client devices; invoke the multicast download requesthandler in order to save session information regarding the receivedmulticast request and create another thread of the multi-threadedapplication to service the received multicast request; wherein servicingthe received multicast request by the another thread further comprisesthe processor to: transmit the plurality of packets of data from theserver device to the one or more client devices using a multicasttrivial file transfer protocol (TFTP) as a TFTP-compliant flow; andapply one or more flow control techniques not defined by the multicastTFTP to the TFTP-compliant flow, wherein the flow control techniquescomprise determining whether the server device has sufficient resourcesto satisfy the request based on a block size corresponding to therequest and an available bandwidth, and sending an error packet to thefirst client device if the server device does not have sufficientresources to satisfy the request, wherein applying, by the server, oneor more flow control techniques not defined by multicast TFTP comprisedelaying a start of the transmission of the plurality of packets,wherein delaying includes if a packet is lost and a send delay isdetermined to be zero, the send delay of zero is set to one, and if thesend delay is determined to be greater than timeout/four, the send delayis set equal to the timeout/four, wherein the send delay is doubled orthe send delay is decreased by one for a number of successful packetsreceived until the send delay reaches zero, wherein the number ofsuccessful packets received includes ten.
 8. The server of claim 7wherein the one or more flow control techniques not defined by multicastTFTP comprises determining whether a request to download the file is asubject of an existing multicast download session, and causing themultiple client devices to join an existing multicast groupcorresponding to the existing multicast download session.
 9. The serverof claim 7 wherein the one or more flow control techniques not definedby multicast TFTP comprises modifying quality of service based, at leastin part, on resource conditions.
 10. The server of claim 9 whereinmodifying the quality of service comprises one or more of: modifyingblock size and modifying timeout length.
 11. The server of claim 7wherein the one or more flow control techniques not defined by multicastTFTP comprises reducing a packet transmission rate.
 12. A non-transitorycomputer-readable medium having stored thereon instructions that, whenexecuted by one or more processors, cause the one or more processors to:execute a multi-threaded application having at least one thread tomonitor a port of a server device for received requests from a pluralityof client devices; execute at least three request handlers to manage anyof the received requests from the plurality of client devices, the atleast three request handlers comprising an upload request handler, amulticast download request handler and a unicast download requesthandler; detect that a multicast request is received from a first clientdevice of the plurality of client devices; invoke the multicast downloadrequest handler in order to save session information regarding thereceived multicast request and create another thread of themulti-threaded application to service the received multicast request;wherein servicing the received multicast request by the another threadfurther comprises the server device to: transmit the plurality ofpackets of data from the server device to the multiple client devicesusing a multicast trivial file transfer protocol (TFTP) as aTFTP-compliant flow; and apply one or more flow control techniques notdefined by the multicast TFTP to the TFTP-compliant flow, wherein theflow control techniques comprise determining whether the server devicehas sufficient resources to satisfy the request based on a block sizecorresponding to the request and an available bandwidth, and sending anerror packet to the first client device if the server device does nothave sufficient resources to satisfy the request, wherein applying, bythe server, one or more flow control techniques not defined by multicastTFTP comprise delaying a start of the transmission of the plurality ofpackets, wherein delaying includes if a packet is lost and a send delayis determined to be zero, the send delay of zero is set to one, and ifthe send delay is determined to be greater than timeout/four, the senddelay is set equal to the timeout/four, wherein the send delay isdoubled or the send delay is decreased by one for a number of successfulpackets received until the send delay reaches zero, wherein the numberof successful packets received includes ten.
 13. The medium of claim 12wherein the instructions that cause the one or more processors to apply,by the server, one or more flow control techniques not defined bymulticast TFTP comprise instructions that, when executed, cause the oneor more processors to: determine whether a request to download the fileis a subject of an existing multicast download session; and cause themultiple client devices to join an existing multicast groupcorresponding to the existing multicast download session.
 14. The mediumof claim 12 wherein the instructions that cause the one or moreprocessors to apply, by the server, one or more flow control techniquesnot defined by multicast TFTP comprise instructions that, when executed,cause the one or more processors to modify quality of service based, atleast in part, on resource conditions.
 15. The medium of claim 12wherein the instructions that cause the one or more processors to apply,by the server, one or more flow control techniques not defined bymulticast TFTP comprise instructions that, when executed, cause the oneor more processors to reduce a packet transmission rate.